Configuring IP-to-IP Inbound Manipulations

The Inbound Manipulations table lets you configure up to 205 IP-to-IP Inbound Manipulation rules. An Inbound Manipulation rule defines a manipulation sequence for the source or destination SIP URI user part of inbound SIP dialog requests. You can apply these manipulations to different SIP dialog message types (e.g., INVITE or REGISTER) and SIP headers as follows:

■ Manipulated destination URI user part are done on the following SIP headers: Request-URI and To
■ Manipulated source URI user part are done on the following SIP headers: From, P-Asserted-Identity (if exists), P-Preferred-Identity (if exists), and Remote-Party-ID (if exists)

Manipulated URI user part of the SIP From and Request-URI headers overwrite the user part of other headers.

Configuration of Inbound Manipulation rules includes two areas:

■ Match: Defines the matching characteristics of an incoming SIP dialog (e.g., source host name).
■ Action: Defines the action that is done if the incoming call matches the characteristics of the rule. In other words, the device manipulates the source or destination SIP URI user part of the SIP dialog (e.g., removes a user-defined number of characters from the left of the SIP URI user part).

Configure stricter classification rules higher up in the table than less strict rules to ensure the desired rule is used to manipulate the incoming dialog. Strict refers to the number of matching characteristics configured for the rule. For example, a rule configured with source host name and source IP Group as matching characteristics is stricter than a rule configured with only source host name. If the rule configured with only source host name appears higher up in the table, the device ("erroneously") uses the rule to manipulate incoming dialogs matching this source host name (even if they also match the rule appearing lower down in the table configured with the source IP Group as well).

To configure and apply an Inbound Manipulation rule, the rule must be associated with a Routing Policy. The Routing Policy associates the rule with an SRD(s). Therefore, the Routing Policy lets you configure manipulation rules for calls belonging to specific SRD(s). However, as multiple Routing Policies are relevant only for multi-tenant deployments (if needed), for most deployments, only a single Routing Policy is required. As the device provides a default Routing Policy ("Default_SBCRoutingPolicy"), when only one Routing Policy is required, the device automatically assigns the default Routing Policy to the routing rule. If you are implementing LDAP-based routing (with or without Call Setup Rules) and/or Least Cost Routing (LCR), you need to configure these settings for the Routing Policy (regardless of the number of Routing Policies employed). For more information on Routing Policies, see Configuring SBC Routing Policy Rules.

The IP Groups table can be used to configure a host name that overwrites the received host name. This manipulation can be done for source and destination IP Groups (see Configuring IP Groups).

The following procedure describes how to configure Inbound Manipulation rules through the Web interface. You can also configure it through ini file [IPInboundManipulation] or CLI (configure voip > sbc manipulation ip-inbound-manipulation).

➢ To configure an Inbound Manipulation rule:
1. Open the Inbound Manipulations table (Setup menu > Signaling & Media tab > SBC folder > Manipulation > Inbound Manipulations).
2. Click New; the following dialog box appears:

3. Configure the Inbound Manipulation rule according to the parameters described in the table below.
4. Click Apply.

Inbound Manipulations Table Parameter Descriptions

 

 

'Routing Policy'

routing-policy-name

[RoutingPolicyName]

Assigns an Routing Policy to the rule. The Routing Policy associates the rule with an SRD(s). The Routing Policy also defines default LCR settings as well as the LDAP servers if the routing rule is based on LDAP routing (and Call Setup Rules).

If only one Routing Policy is configured in the Routing Policies table, the Routing Policy is automatically assigned. If multiple Routing Policies are configured, no value is assigned.

To configure Routing Policies, see Configuring SBC Routing Policy Rules.

Note: The parameter is mandatory.

General

'Index'

[Index]

Defines an index number for the new table record.

Note: Each table row must be configured with a unique index.

'Name'

manipulation-name

[ManipulationName]

Defines an arbitrary name to easily identify the manipulation rule.

The valid value is a string of up to 40 characters. By default, no value is defined.

Note: The parameter value can't be configured with the character string "any" (upper or lower case).

'Additional Manipulation'

is-additional-manipulation

[IsAdditionalManipulation]

Determines whether additional SIP URI user part manipulation is done for the table entry rule listed directly above it.

■ [0] No = (Default) Regular manipulation rule (not done in addition to the rule above it).
■ [1] Yes = If the above row entry rule matched the call, consider this row entry as a match as well and perform the manipulation specified by this rule.

Note: Additional manipulation can only be done on a different SIP URI, source or destination, to the rule configured in the row above as configured by the 'Manipulated URI' parameter (see below).

'Manipulation Purpose'

purpose

[ManipulationPurpose]

Defines the purpose of the manipulation.

■ [0] Normal = (Default) Inbound manipulations affect the routing input and source and/or destination number.
■ [1] Routing input only = Inbound manipulations affect the routing input only, retaining the original source and destination number.
■ [2] Shared Line = Used for the Shared-Line Appearance feature. This manipulation is for registration requests to change the destination number of the secondary extension numbers to the primary extension. For more information, see Configuring BroadSoft's Shared Phone Line Call Appearance for Survivability.

Match

'Request Type'

request-type

[RequestType]

Defines the SIP request type to which the manipulation rule is applied.

■ [0] All = (Default) All SIP messages.
■ [1] INVITE = All SIP messages except REGISTER and SUBSCRIBE.
■ [2] REGISTER = Only REGISTER messages.
■ [3] SUBSCRIBE = Only SUBSCRIBE messages.
■ [4] INVITE and REGISTER = All SIP messages except SUBSCRIBE.
■ [5] INVITE and SUBSCRIBE = All SIP messages except REGISTER.

'Source IP Group'

src-ip-group-name

[SrcIpGroupName]

Defines the IP Group from where the incoming INVITE is received.

The default is Any (i.e., any IP Group).

'Source Username Pattern'

src-user-name-pattern

[SrcUsernamePrefix]

Defines the source SIP URI user name (usually in the From header).

The default is the asterisk (*) symbol (i.e., any source user name). You can use special pattern notations to denote the user part. For available notations, see Dialing Plan Notation for Routing and Manipulation.

'Source Host'

src-host

[SrcHost]

Defines the source SIP URI host name - full name (usually in the From header).

The default is the asterisk (*) symbol (i.e., any host name).

'Destination Username Pattern'

dst-user-name-pattern

[DestUsernamePrefix]

Defines the destination SIP URI user name, typically located in the Request-URI and To headers.

The default is the asterisk (*) symbol (i.e., any destination user name). You can use special pattern notations to denote the user part. For available notations, see Dialing Plan Notation for Routing and Manipulation.

'Destination Host'

dst-host

[DestHost]

Defines the destination SIP URI host name - full name, typically located in the Request URI and To headers.

The default is the asterisk (*) symbol (i.e., any destination host name).

Operation Rule - Action

'Manipulated Item'

manipulated-uri

[ManipulatedURI]

Determines whether the source or destination SIP URI user part is manipulated.

■ [0] Source = (Default) Manipulation is done on the source SIP URI user part.
■ [1] Destination = Manipulation is done on the destination SIP URI user part.

'Remove From Left'

remove-from-left

[RemoveFromLeft]

Defines the number of digits to remove from the left of the user name prefix. For example, if you enter 3 and the user name is "john", the new user name is "n".

'Remove From Right'

remove-from-right

[RemoveFromRight]

Defines the number of digits to remove from the right of the user name prefix. For example, if you enter 3 and the user name is "john", the new user name is "j".

Note: If both 'Remove From Right' and 'Leave From Right' parameters are configured, the 'Remove From Right' setting is applied first.

'Leave From Right'

leave-from-right

[LeaveFromRight]

Defines the number of characters that you want retained from the right of the user name.

Note: If both 'Remove From Right' and 'Leave From Right' parameters are configured, the 'Remove From Right' setting is applied first.

'Prefix to Add'

prefix-to-add

[Prefix2Add]

Defines the number or string that you want added to the front of the user name. For example, if you enter 'user' and the user name is "john", the new user name is "userjohn".

'Suffix to Add'

suffix-to-add

[Suffix2Add]

Defines the number or string that you want added to the end of the user name. For example, if you enter '01' and the user name is "john", the new user name is "john01".